Media transmission in a multiparty videoconference is characterized by multiple one-to-many semantics. One basic mechanism that provides this one-to-many data delivery is IP multicast. However, IP multicast relies on hardware to provide the multicast support. Spotty deployment of multicast-enabled routers has caused many multipoint communication applications to fail. Developers have since turned to “multiple unicast” to implement one-to-many communication. Multiple unicast, however, has some problems too. In contrast to IP multicast, which ensures only one packet on any physical link, multiple unicast replicates data at the source, making the “last mile” (the first mile in this usage) a severe bottleneck. Multiple unicast is also unable to limit throughput to accommodate the most incapable member in a multiparty videoconference, as connectivity on the Internet is heterogeneous, ranging from high speed T1 lines, cable modems, and ADSL, to slow-speed dial-up connections.
There has been a surge of application-level multicast (ALM) systems designed for various types of applications. However, different Internet applications have their distinct requirements for bandwidth, latency and scalability. Table 1 offers a comparison of four typical Internet applications. As shown in Table 1, videoconferencing has a lower scalability requirement than do the other three applications, but demands more bandwidth and is more latency sensitive. Therefore, ALM systems that work for the other applications listed in Table 1 are not directly applicable to videoconferencing applications.
TABLE 1Characteristics of Internet ApplicationsApplicationBandwidthLatencyScaleInternet content distributionMiddleLowLargePeer-to-peer media streamingHighMiddleLargeLow-bandwidth data streamingLowLowLargeMultiparty videoconferencingHighHighSmall
Four conventional ALM protocol designs represent the universe of conventional videoconferencing applications. First, “End System Multicast” provides a fully distributed protocol, named NARADA. NARADA adopts a mesh-first strategy in building multicast trees: end systems self-organize into a rich connected graph (mesh), on top of which data delivery trees are generated based on a distance vector protocol. The main disadvantage of NARADA is that it does not consider the effect of building multiple delivery trees over the same mesh. Since the only routing metric used in the distance vector protocol is end-to-end delay, NARADA does not have any control over the bandwidth usage of each link. As a result, short links can get congested easily when there are numerous participating members.
Differing from NARADA, ALMI is a centralized protocol. Each ALMI session has a session controller, which is responsible for member registration and multicast tree generation. ALMI takes multiple data sources into consideration, and uses a shared tree to handle routing. The shared tree is formed as a minimum spanning tree (MST) based on end-to-end measurements, i.e., round trip delays collected by session members. Although efficiency of the ALMI tree approaches the efficiency of IP multicast trees in terms of total tree cost, the end-to-end delivery delays of ALMI trees are much longer. Moreover, the network load of leaf nodes and inner nodes differs greatly when multiple data sources exist. Since ALMI does not control the bandwidth usage as NARADA does, the inner nodes can get overloaded as the conference size increases.
In contrast to NARADA and ALMI, the protocol used in “multi-sender 3D video conferencing” explicitly addresses multi-sender requirements in a videoconferencing application. This technique uses a double-algorithm approach for managing soft join requests (subscriptions to a stream). The key shortcoming of this protocol, as the authors point out, is its static nature with regard to network conditions. For example, it assumes that all the members of a videoconference have the same static bit rates for data streams.
DIGIMETRO builds multiple source-specific delivery trees in a fully distributed manner. DIGIMETRO considers the effect of having multiple data sources in the same session, and adopts a two-step process to achieve sub-optimal performance. The main advantage of DIGIMETRO over the previous work is that the multicast tree is constructed and refined under dynamically changing network parameters, and it allows different data sources to have different stream bit rates. A multiparty videoconferencing system DIGIPARTY has been implemented using DIGIMETRO.
There are several drawbacks of the existing ALM protocols on the real network. First, both DIGIMETRO and multi-sender 3D video-conferencing assume that the bandwidth bottleneck always occurs in the first mile, which is not true for local area network (LAN) users. Second, NARADA and ALMI only limit bandwidth usage by giving a rough fan-out range, they do not control how many times outbound links are used. Except for ALMI, the other three references described above build source-specific multicast trees to optimize delay performance under certain bandwidth constraints. They tend to aggressively use up local bandwidth resources, however, and have a strong tendency to become multiple unicast. None of the above-mentioned ALM protocols make use of IP multicast, which is usually available in LANs. What is needed is an ALM schema that is more specifically tailored to the needs of videoconferencing.